The mechanics of setting up user specific data security for use with strict subscriptions requires nuanced setup to operate correctly. If your system administrators have elected to use "Strict Subscriptions," then each user receiving output will be sent content that is secured with their own data security settings. As a subscription builder, you can enroll other users or groups of users via roles.
The following explains how to setup the role mechanics to ensure they are useful for Strict Subscriptions while still allowing user-specific security.
Strict Requirements
To use strict subscriptions, the subscription designer needs to ensure that users and roles have security rights to BOTH the content item and its underlying data source(s). It follows that the content item must be shared in a workgroup or public folder and the security and data access for the item and model have been set. Since data security by user needs to be resolved, the security on data source must also function via Pyramid's data security mechanics only. If these conditions are not met, the user or role cannot be added to the subscription.
When the subscription is executed at its designated time, each user or user enumerated in the role is evaluated for access again. If the user lacks access, their subscription task will fail and the results will not be rendered or shared with the user.
Role Setup
The role mechanism requires some careful setup to ensure that the role enumeration works while allowing user-specific security on the data source. This can be achieved through 2 techniques described below.
Public Roles and Private Roles
In this technique, administrators use the point and click process for setting up security on a data model for the roles and each user.
Administrators :
- Setup one or more public roles on a data model source which will be used to drive role-based subscriptions.
- Setup each user's private role to the data model's security setup.
- For the hierarchy to be secured:
- set all of its elements to "disabled" in the security panel for the public role(s). This is CENTRAL to the mechanism.
- select the elements in the hierarchy that should be accessible by each user for each of their private roles
The public roles will allow strict subscription to operate, while the private roles will allow the end-user data security to apply without being resolved through the public role.
Public roles, security tables and scripted security
In this technique, administrators use the scripting process for setting up security on a data model use the public role only in conjunction with security tables and/or columns.
Administrators:
- Setup one or more public roles on a data model source which will be used to drive role-based subscriptions.
- For the hierarchy to be secured administrators build a security script for the relevant hierarchy for the public role, resolving the security of elements by each user as needed. The security tables added and flagged in the data model are CENTRAL to this mechanism, allowing security scripting to be operational.
The public roles will allow strict subscription to operate and will also resolve the end user security WITHOUT using private roles.
This security mechanism is ultimately easier and more performant than the alternative approach.